Harness Engineering（驾驭工程）

Harness Engineering 可以理解为：当 AI 智能体开始参与真实的软件生产后，工程师不再把主要精力放在“亲手写每一行代码”上，而是转向设计一整套能让智能体稳定工作的环境、约束、验证和反馈系统。

如果说大模型是“大脑”，那么 harness 就是把这颗大脑接入真实世界的操作系统、工具链、护栏和质检流水线。没有 harness，模型只能“会回答”；有了 harness，模型才可能“会做事，而且做事过程可控、可验证、可迭代”。

一、为什么 Harness Engineering 会在 2026 年突然变热

核心原因只有一个：AI 生成代码的速度，已经明显快过人类逐行审查和验证代码的速度。

这意味着软件工程的主要瓶颈发生了迁移：

过去的瓶颈是“写得慢”
现在的瓶颈越来越变成“不能快速信任产出”

当智能体可以持续读仓库、改代码、跑测试、提交 PR 时，团队真正要解决的问题就不再只是提示词怎么写，而是：

如何让它拿到正确的上下文
如何限制它的权限边界
如何让它自动验证结果
如何在失败后快速纠偏
如何把同类错误一次性工程化消灭

这套问题的总和，就是 Harness Engineering。

二、什么是 Harness，什么是 Harness Engineering

1. Harness 是什么

在 AI / Agent 语境里，Harness 指的是套在模型外面的那整套运行与控制系统，通常包含：

任务编排
工具调用
上下文管理
记忆机制
权限控制
测试与验证
可观测性
人工审批与回滚机制

一句话说，Harness 的作用是把“会推理的模型”变成“能完成任务的系统”。

2. Harness Engineering 是什么

Harness Engineering 是围绕这套外部系统进行建设和优化的工程方法。

它强调的不是“让模型一次回答更漂亮”，而是“让智能体在真实工作流里持续、稳定、低返工地交付结果”。

一个很有代表性的定义是：

每当发现智能体犯错，就花时间设计一个解决方案，确保它以后不再犯同样的错误。

这句话抓住了 Harness Engineering 的本质：它不是一次性的 prompt 微调，而是一种持续积累“错误模式 -> 规则/工具/测试 -> 永久收益”的复利工程。

3. 和几个相近概念的区别

概念	关注点	核心问题
Prompt Engineering	提示词本身	我们怎么说，模型更容易答对？
Context Engineering	给模型看的内容	我们应该给它哪些信息？
Harness Engineering	系统级控制与反馈闭环	我们如何让它稳定做对，并且错了以后越来越不容易再错？

可以把三者理解成递进关系：

Prompt Engineering 优化单次交互
Context Engineering 优化当前任务的输入组织
Harness Engineering 负责整个系统的长期稳定性、质量和治理

三、Harness Engineering 的核心思想

1. 从“写代码”转向“设计生产系统”

在智能体编码场景里，工程师的角色正在变化：

不再只是亲自实现功能
而是定义目标、约束、架构边界和验收标准
再通过工具链和反馈回路，让智能体去执行

这也是为什么 Harness Engineering 常被概括成一句话：

Humans steer, agents execute.

2. 第一性原则不是“更聪明”，而是“更好验证”

Harness Engineering 最重要的原则，不是让模型看起来更聪明，而是让验证变得更快、更自动化、更客观。

因为当产出速度远快于人工审查速度时，真正可扩展的路径只有两条：

把主观判断尽量变成客观的 pass/fail
把验证成本压缩到秒级或分钟级

所以，测试、lint、结构规则、策略校验、签名、回归检查，这些传统软件工程能力在智能体时代不但没有过时，反而变得更重要了。

3. 失败不是终点，而是 Harness 的输入

一个成熟团队不会把智能体犯错理解成“这次没跑好”，而会继续追问：

它为什么会犯这个错
是知识缺失，还是工具太弱
是规则没写清，还是验证不够快
这个错误能不能被固化成新的测试、lint、脚本或文档结构

这就是 Harness Engineering 的复利来源：同一种错误，不应该靠人反复提醒，而应该被系统性消灭。

四、一个完整 Harness 通常包含什么

1. 上下文与知识系统

智能体看不到“团队默认常识”，它只能依赖你显式提供的上下文。因此，仓库本身必须成为知识系统。

常见做法包括：

用 AGENTS.md 提供入口级说明
将领域知识拆分进结构化 docs/
把构建、测试、发布、调试命令写成可执行规范
用模板和示例减少智能体猜测

这里的重点不是“文档越多越好”，而是“信息结构清晰、可被验证、不过期”。

2. 工具与运行环境

智能体要完成任务，必须有经过约束的执行能力，例如：

文件读写
Shell 命令
测试运行
浏览器自动化
API 调用
本地或远程沙箱

工具不是越多越好。关键在于三点：

能完成当前任务
权限边界清晰
失败信息足够明确，便于智能体自我修正

3. 护栏与约束系统

靠“请遵守规范”无法规模化，必须把约束写进系统。

典型做法有：

依赖方向检查
自定义 lint
文件大小限制
命名规则
输出格式校验
Policy-as-Code
人工审批节点

Harness Engineering 的一个关键变化，就是尽可能让“规范”从口头约定变成机器可执行规则。

4. 验证与反馈闭环

这是 Harness 的核心层。没有验证，智能体只能不断生成；有了验证，它才可能不断逼近正确答案。

常见闭环包括：

单元测试
集成测试
E2E 测试
静态分析
安全扫描
契约测试
失败后自动重试与修复

理想状态是形成一个稳定循环：

写代码 -> 运行验证 -> 接收失败信号 -> 分析原因 -> 修复 -> 再验证

5. 可观测性与评估

如果没有 trace、日志和指标，团队很难知道智能体到底为什么成功、又为什么失败。

因此，成熟的 harness 往往会记录：

输入了什么任务
读了哪些文件
调用了哪些工具
哪一步失败
花了多少 token 和时间
哪类错误最常见

这使 Harness Engineering 不再只是经验主义，而是可以像优化软件系统一样优化智能体系统。

五、为什么 AGENTS.md 很重要，但不能变成“大部头手册”

几份参考材料都反复强调了一个经验：AGENTS.md 很重要，但巨大的、包打天下的说明文件通常会失败。

原因很直接：

上下文窗口有限
信息容易腐烂
智能体无法判断哪些内容已经过期
大量规则混在一起时，可执行性很差

更好的做法是：

用 AGENTS.md 作为“地图”
用拆分良好的 docs/ 作为知识主体
用 lint、CI 或定期维护机制检查文档是否仍然有效

也就是说，好的 agent 文档系统不是一本厚手册，而是一张结构清晰、持续更新的导航图。

六、几个典型案例说明了什么

1. OpenAI：从空仓库到百万行代码

参考材料里最有冲击力的案例，是 OpenAI 在 2025 年 8 月到 2026 年 1 月期间的实践：团队从空仓库出发，用智能体持续生成架构、逻辑、测试、CI 和文档，最后形成约 100 万行代码、约 1500 个 PR 的产品雏形。

这个案例最关键的启示不是“AI 会写很多代码”，而是：

代码仓库必须成为唯一事实来源
工程师的工作重心转向环境、规则和反馈回路
逐行人工 review 不再是主要质量保障方式
智能体必须能直接观察 UI、日志、指标和 trace
系统必须有“垃圾回收”能力，持续清理 AI 生成带来的熵增

2. Mitchell Hashimoto：把错误变成系统收益

Mitchell Hashimoto 对 Harness Engineering 的贡献在于，他把很多团队模糊感受到的东西说清楚了：

智能体犯错不可怕
可怕的是每次都靠人重新纠正
正确做法是把这类错误沉淀成规则、工具和文档

这是非常典型的工程思维。它把“这次修好”升级成“以后都更不容易出错”。

3. LangChain：不换模型，只改 Harness 也能大幅提升效果

另一类案例证明了一个重要事实：系统表现不完全取决于模型。

通过优化 prompt 结构、工具使用方式、中间件、trace 分析和反馈策略，即使不更换底层模型，智能体在编码基准上的表现也可能出现明显提升。

这说明 Harness 不是模型的附属物，而是独立的性能杠杆。

4. Datadog：验证闭环比“读代码”更重要

Datadog 的视角更像是“harness-first engineering”：

不要把希望寄托在人逐行读 AI 生成代码
要投资自动化验证系统
要让生产环境的真实反馈反哺 harness
要尽量把“感觉对”变成“证明确实对”

这个方向对高可靠系统尤其重要，因为一旦智能体具备高吞吐产出能力，验证体系如果跟不上，风险会被成倍放大。

七、Harness Engineering 和传统软件工程是什么关系

Harness Engineering 不是对传统软件工程的替代，而是一次重心迁移。

它本质上是把 DevOps、SRE、Platform Engineering、测试工程和安全工程的一些长期原则，重新放到“智能体参与生产”这个新背景下再组织一遍。

可以这样理解：

DevOps 关注自动化交付
SRE 关注可靠性与反馈控制
Platform Engineering 关注把最佳实践产品化
Harness Engineering 关注如何让智能体也在这套系统里高效而安全地工作

因此，Harness Engineering 的底层并不神秘。它继承的依然是软件工程里最经典的几件事：

自动化
可重复性
可验证性
可追踪性
最小权限
持续改进

不同之处在于，过去这些机制主要是为人服务；现在，它们必须同时为智能体服务。

八、如何在团队里真正落地

1. 先做最小闭环，不要一上来做“大平台”

最实际的起点通常不是“全面智能体化”，而是先让 1 到 2 个仓库具备最小可用 harness：

有清晰的 AGENTS.md
有结构化文档
有稳定的 lint / test / build 命令
有基础安全扫描
有最小可观测性
有明确的 PR 与审批机制

先跑通一个闭环，比设计一套宏大蓝图更重要。

2. 优先建设自动验证层

投资顺序上，最值得优先做的通常不是更复杂的 agent 编排，而是更快、更清晰的验证体系：

单测和集成测试补齐
自定义 lint 补齐
架构边界自动检查
失败日志变得可读
安全扫描与策略检查接入 CI

因为这些东西会直接决定智能体修复问题时能不能快速收敛。

3. 把失败模式沉淀成资产

每次智能体失败，都应该尽量落成某种可复用资产，例如：

一条新规则
一个新测试
一个新脚本
一段更准确的文档
一个新的审批或权限策略

这样团队的 harness 会越来越厚，智能体的稳定性也会随之提高。

4. 把可观测性开放给智能体

如果智能体只能看静态代码，它就只能“猜”系统行为。

更高阶的做法是逐步开放：

页面行为
日志
指标
trace
本地或临时环境实例

让它能真正观察系统运行结果，而不是只从源码推断结果。

5. 最终把最佳实践产品化

当试点跑通后，下一步不是继续堆人工经验，而是把成功做法抽象成团队可复用的 golden path：

标准仓库模板
标准 CI 流水线
标准规则集
标准文档结构
标准 tracing 与评估面板

这一步完成后，Harness Engineering 才真正从“个人技巧”升级为“组织能力”。

九、常见反模式与风险

1. 把文档越写越厚

如果文档只是不断堆叠，而没有结构和校验，它迟早会变成噪音源。智能体不是更容易成功，而是更容易被误导。

2. 继续把人工 review 当成主防线

人工 review 仍然重要，但它更适合做高层判断、边界把关和异常审查，而不是承担所有基础验证。

3. 工具权限过大

如果智能体能直接接触危险命令、敏感密钥或不可信输入源，而又缺乏隔离与审批，风险会被迅速放大。

4. 只有生成，没有垃圾回收

智能体很擅长快速扩张代码和文档，但如果没有重构、收敛和周期性清理，仓库熵会快速升高，最终反过来伤害智能体本身的表现。

5. 把问题都归因于模型

很多失败其实不是模型太弱，而是：

上下文不完整
工具接口差
验证信号太慢
规则没机械化
失败信息不够清晰

这正是 Harness Engineering 存在的意义。

十、一个简洁的落地框架

如果要用一句尽量工程化的话概括，可以记住下面这个定义：

Harness 是围绕 LLM / Agent 搭建的运行环境、工具接口、上下文机制、约束规则、验证反馈与观测体系的总和。

Harness Engineering 是通过持续优化这套体系，让智能体在真实任务中更可靠、更高效、更可控的工程方法。

对团队来说，它最终会落到五件实事上：

把知识组织进仓库，而不是只放在人脑里
把约束写成规则，而不是只写成口头规范
把验证做快做自动，而不是依赖人工兜底
把失败变成资产，而不是一次性修复
把最佳实践产品化，形成组织级复用能力

十一、总结

Harness Engineering 的真正价值，不在于它是一个新名词，而在于它准确描述了 AI 编码时代的软件工程重心变化。

当模型能力越来越商品化，真正拉开差距的往往不再只是“你用了哪个模型”，而是：

你的知识组织得够不够好
你的工具边界清不清楚
你的验证是否足够自动化
你的失败能否快速沉淀为规则
你的团队能否把这些能力平台化

所以，Harness Engineering 说到底不是“如何更会和模型聊天”，而是“如何把智能体纳入软件生产系统，并让它成为一个可控、可审计、可持续优化的生产力单元”。

【笔记】Harness Engineering（驾驭工程）